-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Feature] Component Implementation - Button #34
Conversation
…affairs/va-mobile-library into 6870-nr-vabutton
…affairs/va-mobile-library into 6870-nr-vabutton
…affairs/va-mobile-library into 6870-nr-vabutton
…affairs/va-mobile-library into 6870-nr-vabutton
…affairs/va-mobile-library into 6870-nr-vabutton
}, | ||
} | ||
|
||
export const Primary: Story = { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nitpicky so don't feel strongly, but if there's a simple way within the Doc section to bump Primary to be at the top instead of Base that would probably make more sense.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could not figure out a way to sort these properly. According to Storybook docs, they're supposed to be sorted by the way they are written in code but I'm not finding that to be the case. There's ways to set the manually, but we'd have to list out each story in an array which will be a bit cumbersome to do everytime we add a new story.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, initially tried just moving it to the top and was disappointed to see the sort didn't change. Oh well.
Update: Still didn't look at the updated unit tests yet, but everything else looks good (including testing iOS/Android/Web) except some minor comments. |
|
||
it('should render Primary pressed variant', async () => { | ||
component = render( | ||
<Button label={label} onPress={onPressSpy} testOnlyPressed={true} />, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Was testOnlyPressed
also needed for detox or anything? If not, wonder if there's a way to check the pressed state without needing to add a prop to force it--seems like there should be. Taking a very brief glance at the testing library docs, I see fireEvent.keyDown
exists and wonder if there's similarly a press-and-hold function that would also yield the pressed styles. Or maybe even that one works even though it's not a "key" for us.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Was initially trying to use fireEvent(button, 'pressIn')
which is the RN equivalent, but it was not working to render the pressed styles. testOnlyPressed
was the only one I had success with, but it's not ideal since it has to be exposed as a prop.
const { backgroundColor, borderWidth } = button.props.style | ||
const { color } = text.props.style | ||
|
||
expect(backgroundColor).toEqual( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thought about mentioning it, but you'd already ran with integrating into jest tests which is fine for now.
However: wonder if we should explore other testing options (maybe jest has extensions for it too?) that do an actual UI snapshot to test styles instead of programmatically doing it which is a bit forced. I know at some RN virtual conference back in like 2020 or 2021 there was a presentation on a visual testing library that would just have pictures of before and compare to the after and highlight any differences down to the pixel (intentional or not) to confirm. Probably beyond the scope of this ticket anyway, but maybe worth a spike to explore since that seems a much more intuitive way to unit tests styles if it wasn't too much of a lift. In theory, it'd probably be much quicker/less tedious as well if we committed to style testing every component which likely does make sense for a design system.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Created spike ticket to explore this: https://github.com/department-of-veterans-affairs/va-mobile-app/issues/7319
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Dropping a re-request changes to denote the end of the 2nd pass. Not sure any of the new comments absolutely need changes, but I think some tweaks would be good. I think the only truly outstanding thing is confirming it works in the app now--which the commit I added should hopefully allow.
App runs and I can import the button successfuly, but TypeScript is giving complaints about the web related code:
|
Ugh! Added another commit to fix--adding listeners this way still seems to work with it abstracted out so was able to pull it out similarly to our Expo initialization which should remove those TS complaints because now the code won't exist in the NPM package. I also changed from listening to the top body in favor of the parent body--because I think it would've been bugged when the iframe was within the doc site (since then it'd be listening to the doc site "body" in the HTML at the top level instead of the one "body" above it that the toggle would be switching the className between "light" and "dark". Fun that in normal circumstances there should only be a single "body" in a website, but within the doc site there's 3: the doc site's, storybook's, and the component's (or 3 layers I guess, more if you account for each iframe having 2 body's each). |
Checking iOS I see my follow-up fix caused a require cycle. Should be fine, but will give us an annoying warning in iOS/Android. I'd say we should move to attempt to implement ticket 7194 over resolving the require cycle by effectively making a duplicate structure for try-catching a different file than circling back to main.tsx. |
@TimRoe Tested within the app and errors are gone. Thanks! Here is an example of the the button being used on the Login screen: Simulator.Screen.Recording.-.iPhone.15.Pro.-.2023-11-16.at.12.00.08.mp4Address all other feedback. Ready for another round of review. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Approved, good to go through the publish checklist creating components package v0.2.0 and merge.
Ticket department-of-veterans-affairs/va-mobile-app#6870
Description of Change
Notable differences from original VAButton
Breaking changes
Testing Packages
Screenshots/Video
iOS
Simulator.Screen.Recording.-.iPhone.15.Pro.-.2023-11-08.at.10.57.06.mp4
Android
Screen.Recording.2023-11-08.at.11.04.02.AM.mov
Web
Screen.Recording.2023-11-08.at.11.20.11.AM.mov
White variant usage in mobile app
Simulator.Screen.Recording.-.iPhone.15.Pro.-.2023-11-16.at.12.00.08.mp4
Testing
PR Checklist
Code reviewer validation:
Publish
If changes warrant a new version per the versioning guidelines and the PR is approved and ready to merge:
main
into branchmain